Latest Report | Participation Agreement | API | Validation | Encryption
The table provides a summary of all algorithms measured on attack presentation classification error rate (APCER) when bona fide classification error rate (BPCER) is set to 0.1 and 0.01, across different morphing datasets. APCER, or morph miss rate, is the proportion of morphs that are incorrectly classified as bona fides (nonmorphs). BPCER, or false detection rate, is the proportion of bona fides falsely classified as morphs.
Website
Global Morph
Local Morph
Local Morph Colorized Average
Local Morph Colorized Match
Complete
Splicing
Combined
UNIBO Automatic Morphed Face Generation Tool v1.0
DST
Manual
Lincoln
All prior Ongoing FRVT MORPH reports can be accessed from here.
Face morphing and the ability to detect it is an area of high interest to a number of photo-credential issuance agencies and those employing face recognition for identity verification. The FRVT MORPH test will provide ongoing independent testing of prototype face morph detection technologies. The evaluation is designed to obtain an assessment on morph detection capability to inform developers and current and prospective end-users, and will evaluate two separate tasks:
We are seeking representative morph data to support our testing efforts. If your organization has morphs that 1) have never been shared with developers and 2) can be shared with NIST, please contact frvt@nist.gov.
FRVT MORPH is conducted by NIST, an agency of the United States Government. Participation is free of charge. FRVT MORPH is open to a global audience of computer vision and face recognition developers. All organizations who seek to participate in FRVT MORPH must sign and submit all pages of this Participation Agreement. Note that this is a separate agreement from the FRVT Ongoing 1:1 agreement. [last update: 2018-06-11]
An updated version of the FRVT MORPH API document is now available. All FRVT APIs reference the supporting FRVT General Evaluation Specifications, which includes hardware and operating system environment, software requirements, reporting, and common data structures that support the APIs. Developers must ensure that their submission conforms to the API specifications. [last update: 2019-06-12]
An updated validation package has been published to reflect the API changes. All participants must run their software through the validation package prior to submission. The purpose of validation is to ensure consistent algorithm output between your execution and NIST’s execution. [last update: 2019-06-12]
All submissions must be properly encrypted and signed before transmission to NIST. This must be done according to these instructions using the FRVT Ongoing public key linked from this page. Participants must email their public key to NIST. The participant’s public key must correspond to the participant’s public-key fingerprint provided on the signed Participation Application. [last update: 2018-05-10]
Please contact NIST if
Inquiries and comments may be submitted to frvt@nist.gov.
Subscribe to the FRVT mailing list to receive emails when announcements or updates are made.